Amazon RDS 障害問い合わせ時の初動調査についてまとめてみた

AWSテクニカルサポートノート

#AWS

#Amazon RDS

#Amazon Aurora

村上紗敏

2022.07.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon RDS の障害でお問い合わせをいただいた際に、どのように調査をしているかについてまとめてみました。
ポイントとなるのは、大きな視点から調べていき、徐々に網を絞っていく方針です。

1.AWS Health Dashboard の確認

以前は、Personal Health Dashboard（AWS アカウント固有の障害通知）と Service Health Dashboard（ AWS サービスとリージョンでの障害報告）の 2 つを確かめていましたが、現在は AWS Health Dashboard 一つに統合されました。
AWS Health Dashboard をご確認していただくことで、「緊急のハードウェアメンテナンスが行われた」、「RDS に関連するサービスに障害があり、それが起因となり RDS へ接続できなくなった」等に気づくことができます。

AWS Health Dashboard 画面

[アップデート] Service Health Dashboard と Personal Health Dashboard が統合されて AWS Health Dashboard になりました

2.メンテナンスウィンドウの設定時間

RDS への接続が一定時間できなくなった！
予期しない再起動イベントが発生した！

上記のような場合には、障害発生時刻とメンテナンスウィンドウが重なっていないかを確認してみると、メンテナンスウィンドウにおいてマイナーバージョン自動アップグレードが実行されていた、リソースをオフラインにする必要があるメンテナンスが実行されていたということがあります。

また、RDS Aurora クラスターにおいては、クラスターのメンテナンスウィンドウと各インスタンスのメンテナンスウィンドウをそれぞれ設定する必要があり、インスタンスのメンテナンスウィンドウについては設定がデフォルトのままとなっていたということもありました。

クラスターのメンテナンスウィンドウ

メンテナンスウィンドウが mon:14:21-mon:14:51 UTC (GMT) で設定されています。

ライターインスタンスのメンテナンスウィンドウ

メンテナンスウィンドウが sat:13:45-sat:14:15 UTC (GMT) で設定されています。

本ブログをきっかけにして、RDS のメンテナンスウィンドウについてご確認をいただけると嬉しいです。 Amazon Aurora DB クラスターのメンテナンス

一部のメンテナンス項目では、Amazon RDS が DB クラスターを少しの間オフラインにする必要があります。リソースをオフラインにする必要があるメンテナンス項目には、必要なオペレーティングシステムやデータベースのパッチが含まれます。

Amazon RDS メンテナンスウィンドウ

すべての DB インスタンスには週次のメンテナンスウィンドウがあり、その期間内にシステムの変更が適用されます

3.データベースイベントの確認

マネジメントコンソール上において、Amazon RDS に関連する 24 時間以内の下記イベントを確認することができます。

・DB インスタンスイベント
・DB パラメータグループイベント
・DB セキュリティグループイベント
・DB スナップショットイベント
・RDS Proxy イベント
・カスタムエンジンバージョンイベント

マネジメントコンソール上でのイベント表示 Amazon RDS イベントの表示

ただし、24 時間より前に発生したイベントについては AWS CLI での確認が必要となりますので、下記 AWS CLI コマンドを実行して直近 2 週間のイベントを確認します。

aws rds describe-events --source-identifier --source-type db-instance --duration 20160

上記コマンドを実施いただくことで、調査対象のインスタンスにフェールオーバーが発生した等の RDS イベントを確認することができます。

describe-events コマンド実行結果画面

describe-events — AWS CLI 2.4.1 Command Reference

4.CloudWatch で各メトリクスを調べる

AWS Health Dashboard から RDS イベントまで確認をしてみて、なお障害の原因が不明の場合は、CloudWatch の各メトリクスを調べます。
また、CloudWatch メトリクスを調べることにより、フェールオーバー発生の原因等も分かる場合があります。
お問い合わせをいただいた事象により注目するメトリクスは変わりますが、よく利用する代表的なメトリクスについてご紹介します。

メトリクス	コンソール名	説明
CPU Utilization	CPU 使用率 (%)	CPU 使用率。
CPU CreditBalance	CPU クレジット残量 (数)	(T2 インスタンス) インスタンスが起動またはスタート後に蓄積した獲得 CPU クレジットの数。
Database Connections	CPU 使用率 (%)	データベースインスタンスへのクライアントネットワーク接続の数。
FreeableMemory	解放可能なメモリ (MB)	使用可能な RAM の容量。
FreeStorage Space	空きストレージ領域 (MB)	使用可能なストレージ領域の容量。
SwapUsage	スワップ使用状況 (MB)	DB インスタンスで使用するスワップ領域の量。

Amazon RDS の Amazon CloudWatch メトリクスより引用。

上記のご紹介したメトリクス以外にも、お問い合わせいただいた事象によってネットワークのスループット（IN/OUT）や、IOPS (読み取り/書き込みリクエスト) についてのメトリクスを一つ一つ調べていきます。

具体的な例を挙げますと、T2 系インスタンスで急にパフォーマンスが悪化したとお問い合わせをいただいた場合は、まず CPUCreditBalance が枯渇していないかを確認してから、他メトリクスを調べることとなります。

CPU使用率に問題がないのに、EC2インスタンスの動作が不安定になった時の切り分けと対処

他には Aurora でフェールオーバーが発生したとのお問い合わせをいただいた場合は、AuroraReplicaLag メトリクスを調べることでレプリカラグが増加したことによりフェールオーバーが発生した可能性を調べます。
Amazon Aurora では、レプリカラグが 100 ミリ秒を超えて継続した場合に障害と判断しフェールオーバーが発生することがある為です。（レプリカラグが 100 ミリ秒を超えたら必ずフェールオーバーするわけではありません。）

メトリクス	コンソール名	説明
AuroraReplicaLag	Aurora でのレプリカ遅延 (ミリ秒)	Aurora レプリカについて、プライマリインスタンスからアップデートをレプリケートする際の遅延時間。

Amazon Aurora の Amazon CloudWatch メトリクスより引用。

Amazon Aurora でのレプリケーション

このラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。レプリカラグは、データベースの変更レートによって異なります。つまり、データベースに対して大量の書き込みオペレーションが発生している間、レプリカラグが増加することがあります。

以降の調査について

以降の調査については、拡張モニタリングや Performance Insights、各種ログを利用して調査することとなります。
また、AWS 基盤側の障害について可能性がある場合は、弊社テクニカルサポートの調査結果を添えて AWS へ調査を依頼する場合があります。

・拡張モニタリング （有効化が必要）
拡張モニタリングを使用した OS メトリクスのモニタリング

・Performance Insights（有効化が必要）
Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング

・各種ログ
最終的には、ログを用いて調査をすることとなります。
Amazon CloudWatch Logs とは

まとめ

RDS の障害お問い合わせをいただいた際に、普段の業務でどのように調査しているかについてまとめてみました。
実際には、RDS 単体の問題ではなく接続元アプリ側に問題があったり、オンプレからの接続の場合は VPN や DirectConnect 等の通信経路に問題がある可能性もある為、ネットワークのトラブルシューティングが必要になることもあります。
本ブログを参考にしていただき、RDS でトラブルが発生した際の対応に役立てていただけば幸いです。